1. Field of the Invention
present invention generally relates to data compression schemes, and more particularly to a data compression method and apparatus based on the LZW algorithm.
2. Description of the Prior Art
Recently, a variety of data, such as character codes, vector information and image information is processed by a computer. Further, the quantity of data processed by the computer is rapidly increasing. In order to efficiently process a large quantity of data at a high speed, it is necessary to exploit redundant parts of the data. A universal coding capable of compressing a variety of data by a single compression algorithm has been proposed. In this specification, data amounting to one word will be referred to as a "character", and data corresponding to a plurality of consecutive words will be referred to as a "character string".
The Ziv-Lempel coding is known as one of the typical universal encoding procedures (see, S. Munataka, "Ziv-Lempel Data compression Algorithms", Information Processing, Vol. 26, No. 1, 1985, pp. 2-6, the disclosure of which is hereby incorporated by reference). A universal type algorithm and an incremental parsing algorithm have been proposed as suitable algorithms of the Ziv-Lempel encoding. Further, an LZSS code is known as an improvement in the universal type algorithm (see T. C. Bell, "Better OPM/L Text Compression", IEEE Trans. on Commun. Vol., COM-34, No. 12, Dec. 1986, pp. 1176-1182, the disclosure of which is hereby incorporated by reference). Meanwhile, an LZW (Lempel-Ziv-Welch) code is known as an improvement in the incremental parsing algorithm (see T. A. Welch, "A Technique for High=Performance Data Compression", Computer, June 1984, pp. 8-19, the disclosure of which is hereby incorporated by reference). Out of the above-mentioned codes, the LZW code is used for file compression in a storage device because the algorithm thereof is simpler than the other algorithms.
A description will now be given of the LZW coding with reference to FIGS. 1, 2 and 3. More specifically, FIG. 1 is a flowchart of an LZW coding procedure, FIG. 2 is a flowchart of an LZW decoding procedure, and FIG. 3 shows the LZW coding and decoding. In FIG. 3, data (message) consisting of combinations of three characters `a`, `b` and `c` is processed for the sake of simplicity.
Referring to FIG. 1, the LZW coding is carried out as follows. At step S1, all partial strings, each consisting of a single character, are registered, as initial values, into a programmable dictionary. After that, the LZW coding starts. A reference number is assigned to each of the partial strings, each consisting of a single character. At step 1, the dictionary is retrieved by the the first input character K, and the reference number corresponding to the first input character K is obtained. The first input character is defined as a prefix string.
At step S2, the second input character K subsequent to the first input character is input, and determined, at step S3, whether or not the first input character K existed. When the result at step S3 is YES, it is determined, at step S4, whether or not a partial string (.omega.K) obtained by adding the second input character K to the reference number .omega. of the first input character has been registered in the dictionary (or has been recognized). When the result obtained at step S4 is NO, at step S6 the reference number .omega. of the character K determined at step S1 is output as a code or code (.omega.) and the partial string (.omega.K) is registered, together with a new reference number, into the dictionary. Further, at step S6, the partial string obtained at at step S2 is replaced by the reference number .omega., and the procedure returns to step S2. Then, the dictionary address, labeled n, for inputting the consecutive characters one by one is incremented by 1. When the result obtained at step S3 is NO, the reference number .omega. is output as the code (.omega.) at step S7. In this way, the above-mentioned procedure is repeatedly carried out until it is recognized that the dictionary does not have any partial string (.omega.K).
An example of the LZW coding will now be described with reference to (A) and (B) of FIG. 3. Input data shown in (A) of FIG. 3 is read from left to right. The first character `a` is searched for in a dictionary 10. It will be noted that three partial strings `a`, `b`, and `c` have been registered before starting coding. Since the first character has been registered in the dictionary 10, its extended string obtained by adding the second input character to the first input character, namely, `ab`, is searched for in the dictionary. At this time, the dictionary 10 does not have any extended strings. Thus, the code (.omega.), that is, code 1 is output for this string, and reference number 4 is assigned to the partial string `ab`. In actuality, the reference number 4 is registered in the form of .omega.K. That is, the partial string `ab` is described as 1b. Then, the second input character b is used to start the next string. Since its extension `ba` is not in the dictionary 10, it is put there under reference number 5, the code for `b` is output, and `a` starts the next string. The above-mentioned process continues straightforwardly.
Referring to FIG. 2, the LZW decoding procedure, which is the reverse procedure of the LZW coding procedure, is carried out as follows. At step S11, all partial strings, each consisting of one character, are registered, together with respective reference numbers, in a dictionary on the decoding side. At step S1, the first code (reference number) is read, and a variable CODE indicating the current code is replaced by a variable OLD code. Since the first code always corresponds to the reference number of one of the characters already registered in the dictionary, the character Code (K) corresponding to the variable CODE is searched for, and the character K is output. The output character (K) is written into a variable FINchar used for an exception procedure at step S18, which will be described in detail later.
At step S12, the next (second) code is read, and written, as INcode, into the variable CODE. At step S13, it is determined whether or not any code input existed. When the result at step S13 is NO, the procedure ends. On the other hand, when the result at step S13 is YES, it is determined, at step S14, whether or not the code CODE defined at step S12 has been defined (registered) in the dictionary. When the result obtained at step S14 is NO, the procedure proceeds to step S15, at which step it is determined whether or not the partial string (.omega.K) corresponding to the code CODE has been registered in the dictionary. When the result at step S15 is YES, the partial string K is temporarily stacked, and the reference number code (.omega.) is written into the variable CODE. Then, the procedure returns to step S15. Steps S15 and S16 are repeatedly carried out until the reference number .omega. becomes equal identical to a single character. When the result at step S15 becomes YES, the characters stacked at step S16 are output by an LIFO (Last In Fast Out) process. At the same time, a new reference number is assigned to a partial string (.omega.K) consisting of the previously used code .omega. and the first character of the partial string decoded this time.
An example of the LZW decoding procedure will be described with reference to (C) and (D) of FIG. 3. The first input code is 1, as shown in (D) of FIG. 3, and the reference numbers of the characters `a`, `b` and `c` have been respectively registered as 1, 2 and 3 in the dictionary, as shown in (C) of FIG. 9. Thus, the first input code 1 is replaced by the partial string `a` having reference number 1. The next (second) input code 2 is replaced by the character `b` in the same way. At this time, the combination of the previously processed code 1 and the presently processed code 2, that is, `1b` is assigned reference number 4, which is registered in the dictionary 10 on the decoder side.
The third input code 4 is replaced by `1b` and then `ab` by retrieving the dictionary 10. At the same time, a partial string `2a` (=`ba`) corresponding to the combination of the previously processed code 2 and the first character `a` of the partial string processed this time is assigned reference number 5, which is registered in the dictionary 10. The above-mentioned process continues straightforwardly.
The LZW decoding procedure has an exception process. This exception process is needed for decoding the sixth input code 8. The code 8 is not registered in the dictionary 10 during the above-mentioned procedure, so that it cannot be decoded. In this case, partial string `5b` is obtained by adding the first character of the partial string `ba` previously decoded to the code 5 previously processed, and is further replaced by `2ab` and then `bab`. Then, the partial string `5b` obtained by adding the first character of the partial string `ba` to the code 5 previously processed is registered, together with reference number 8, in the dictionary 10.
The above-mentioned exception process is executed by steps S14 and S18 shown in FIG. 2. Finally, at step S17, the partial string `bab` is output and the combination (.omega., K) is registered, together with the corresponding reference number, in the dictionary 10.
The LZW coding and decoding procedures respectively shown in FIGS.1 and 2 are carried out while the same dictionary is being created However, it takes a long time to search for one partial string by the LZW coding and decoding procedures In the worst case, it is necessary to retrieve the entire dictionary 10. In order to eliminate this problem and speed up the coding and decoding procedures, an open hashing (chaining) method for dictionary retrieval has been proposed (see "Information Processing Handbook", The Institute of Information Processing, Ohm Corporation).
FIG. 4 shows an outline of the open hashing method The open hashing method defines a hash function for obtaining the address indicating a storage area in which an element x (character string) of a set S made up of character strings on the basis of the element x. The element x is stored in the storage area indicated by the address obtained by the hash function. When storage areas (a hash table) are assigned addresses 0 to m-1, the following hash function, labeled h, is defined as follows: EQU h : S.fwdarw.[0, 1, . . . , m-1]
The address of the element (character string) x in the set S is determined by a hash address h(x). Normally, the hashing procedure is employed in a case where the size of the set S is much greater than m. Even if any hash function h is selected, there is a possibility that h(x1)=h(x2) where x1 and x2 are different character strings in the set S. This is called collision. The open hashing method can cope with such collision
According to the open hashing method, as shown in FIG. 4, a list is provided for each hash address i, and the character strings x which satisfy h(x)=i are put in the same list from the head (beginning) of the list. The list having the same hash address is called a bucket.
FIGS. 5, 6 and 7 show a conventional LZW coding procedure based on the open hashing method. More specifically, FIG. 5 shows a tree structure for dictionary retrieval, FIG. 6 shows the state of a partial string table 10b and the state of an open hash table 10b, and FIG. 7 shows a conventional LZW coding procedure using the open hashing method (see "Hard Disk Cook Book", AP-Labo Inc., Shoeisha, Aug. 15, 1987, pp. A-28-A-34).
Referring to FIG. 6, the partial string table 10b stores a character code for each index i and a character (extension character) Ext[i]. The open hash table 10a consists of two table parts 100 and 101. The table part 100 defines a sequence First, and the table part 101 defines a sequence Next. The table part 100 corresponds to the index dictionary shown in FIG. 4, and the table part 101 corresponds to the linked lists (buckets). The component of the sequence First, First[i], indicates the index (address) showing the first partial string positioned at the beginning of the list specified by the index (reference number) i, and the component of the sequence Next, Next[i], indicates the index (pointer) showing an element which corresponds to a "brother" of the element of the reference number i. The component of the sequence Ext, Ext[i] indicates an extension character added to the ith element of the partial string table.
The open hashing method is intended to calculating, at a high speed, the reference number of a partial string obtained by adding the extension character to the reference number (hash address) i of the previously encountered partial string. The hash table 10a is retrieved by the hash address of the partial string obtained by adding the extension character to the reference number (hash address) i. The list includes information about the extension character which is added to the reference number i. The extension character is compared with the input character K. When both the characters are different from each other, the next extension character indicated by the pointer (address) Next[i] of the extension character which is determined not to be identical to the input character is compared with the input character K. In this way, it is possible to retrieve all one-character-added partial strings which have been encountered. When all one-character-added partial strings have been checked and they do not coincide with the K added partial string, an linked address 0 is finally obtained, so that it is recognized that the identical partial string is not registered.
Referring to FIG. 5, a description will now be given of a procedure for searching for `ahf` when partial strings `ab`, `ah`, `az`, `abf`, `ahd`, `ahf` and `azc` have been registered in the dictionary. The initial state of the partial string table 10b and the open hashing table 10a are as shown in FIG. 6. The first character `a` has been registered in the dictionary. In order to search for the second character `h`, the component First[i=a] of the sequence First is referred to by the hash address `a`, so that P1 is obtained. Thereby, the partial string `ab` starting from `a` indicated by the index P1 is found. However, the second character of the partial string `ab` is not the same as that of the partial string `ahf`. Then, the sequence Next is retrieved by the hash address P1, so that P2 is obtained. The partial string indicated by the index P2 is `ah`, the second character of which is the same as that of the partial string `ahf`. Then, the third character `f` of the partial string `ahf` is searched for. The sequence First is retrieved by the hash address P2, so that P6 is obtained. The third character of the partial string indicated by P6 is `d`, which is not the same as that of the partial string `ahf`. Thus, the sequence Next is retrieved by the hash address P6, so that P7 is obtained. The third character of the partial string indicated by P6 is `f`, which is the same as that of the partial string `ahf`. The route for retrieving the partial string `ahf` is composed of paths 1, 2, 3 and 4 in this order, as shown in FIG. 5.
FIG. 7 shows the above-mentioned LZW coding procedure. At step S20, the dictionary is initialized so that each one-character contained in the input character string is registered. Then, the reference number assigned to the partial string which is next to be registered is written into the variable n. For example, the reference numbers 1, 2 and 3 respectively assigned to characters `a`, `b` and `c` are registered in the dictionary, and reference number 4 is written into the variable n. A maximum number of partial strings Nmax is determined, and the aforementioned sequences First, Next and Ext, each having the maximum number of partial strings are defined. Initially, zero is written into the sequences First, Next and Ext as the initial values. The ith component First[i] of the sequence First shows the number indicating a component of the sequence Ext located at the head of the list corresponding to the node indicated by the reference number i. The ith component Ext[i] of the sequence Ext shows extension character K of an element indicated by the reference number i. Further, the ith component Next[i] has a pointer indicating an element corresponding to a "brother" of the element indicated by the reference number i.
The first character (prefix string) K is read, and the reference number thereof is written into the variable i. Then, the coding procedure starts. At step S21, the next character subsequent to the first character is read as the extension character K. At step S22, it is determined whether or not the first input character K existed. When the result at step S22 is YES, a dictionary retrieval procedure 50 consisting of steps S23-S27 is executed.
At step S23, the variable i is saved in another variable .omega., and an initial value "0" is written into the variable j. At step S24, the number of the component of the sequence Next indicated by the value of the component First[i] corresponding to the variable i is written into the variable i. At step S25, when it is determined that the value of the variable i is not "0", the retrieval procedure for the corresponding list is started. The corresponding list contains one or more candidate elements. At step S26, the component Ext[i] is compared with the extension character K. When the result at step S26 is NO, at step S27 the value of the variable i is save in the variable j, and the component Next[i] serving as a pointer which shows the next candidate element is written into the variable i. By repeatedly executing steps S25-S27, the corresponding list is retrieved.
When it is determined, at step S26, that Ext[i]=K, it is determined that the partial string identical to the input character string has been registered in the dictionary. In this case, the procedure returns to step S21, and the coding procedure for a character string with the next character input at step S21 added is carried out.
On the other hand, when the component First[i] or the component Next[i] corresponding to the variable i is "0", the result at step S25 is YES. In this case, it is recognized that the dictionary does not have any candidate element which is to be linked to the partial string indicated by the reference number i. In this case, a dictionary registration procedure 60 consisting of steps S29-S32 is executed.
The reference number corresponding to the partial string retrieved at step S23 is saved in the variable .omega. each time the partial string is retrieved. Thus, the reference number saved in the variable .omega. shows the already encountered partial string which makes a longest match with the input character string. At step S28, a code corresponding to the reference number .omega. is output, and the new partial string is registered in the dictionary by the steps S29-S32.
At step step S29, the value of the variable n is written into the variable i, and then incremented by 1. Further, the component Ext[i] corresponding to the variable i is set to the extension character K. At step S30, it is determined whether or not the value of the variable j is "0". When the result at step S30 is YES, at step S31 the value of the variable i is written into the component First[.omega.] and the list corresponding to the reference number .omega. is defined. On the other hand, when the result at step S30 is NO, the value of the variable i is written into the component Next[.omega.], the new "brother" is added to the list being considered. At step S33, the reference number corresponding to the extension character K is written into the variable i, and the procedure returns to step S21. When there is no character which is to be input, a code corresponding to the variable .omega. obtained at this time is output at step S34, and the procedure ends.
However, the above-mentioned conventional coding method has the following disadvantages. First, it is not designed to modify the open hash table 10a shown in FIG. 6. That is, it is not designed to change the position of each partial string in the tree structure. Thus, if a partial string which is frequently retrieved is registered at a deep position available via a long route from the root of the tree structure, it takes a long time to access such a partial string because this route must be traced each time it is searched for, so that the retrieval procedure is not executed efficiently. When the coding rate is equal to about 10KB/s, it is impossible to code the input character string in real time so that the coding procedure matches a transfer speed (a few of 100KB/s to 1MB/s) at which coded data is transferred to a storage device, such as a magnetic disk drive or magnetic disk tape device. Second, since each partial string is registered in the tree structure in the order of appearance, if a partial string which is frequently retrieved is registered at a position away from the root of the tree structure, the same problems as described above will occur. Third, the conventional coding procedure is not designed to change the route for retrieval. Thus, the same problems as described above take place.